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Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 
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Abstract 


This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), 
which can be used as a component in a Diff-Serv traffic conditioner 
[RFC2475, RFC2474]. The marker is intended to mark packets that will 
be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB) 
[AFPHB] in downstream routers. The TSWTCM meters a traffic stream and 
marks packets to be either green, yellow or red based on the measured 
throughput relative to two specified rates: Committed Target Rate 
(CTR) and Peak Target Rate (PTR). 


1.0 Introduction 


The Time Sliding Window Three Colour Marker (TSWICM) is designed to 
mark packets of an IP traffic stream with colour of red, yellow or 
green. The marking is performed based on the measured throughput of 
the traffic stream as compared against the Committed Target Rate 
(CTR) and the Peak Target Rate (PTR). The TSWTCM is designed to mark 
packets contributing to sending rate below or equal to the CTR with 
green colour. Packets contributing to the portion of the rate 
between the CTR and PTR are marked yellow. Packets causing the rate 
to exceed PTR are marked with red colour. 


The TSWICM has been primarily designed for traffic streams that will 
be forwarded based on the AF PHB in core routers. 
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The TSWICM operates based on simple control theory principles of 
proportionally regulated feedback control. 


2.0 Overview of TSWTCM 


The TSWICM consists of two independent components: a rate estimator, 
and a marker to associate a colour (drop precedence) with each 
packet. The marker uses the algorithm specified in section 4. If the 
marker is used with the AF PHB, each colour would correspond to a 
level of drop precedence. 


The rate estimator provides an estimate of the running average 
bandwidth. It takes into account burstiness and smoothes out its 
estimate to approximate the longer-term measured sending rate of the 
traffic stream. 


The marker uses the estimated rate to probabilistically associate 
packets with one of the three colours. Using a probabilistic function 
in the marker is beneficial to TCP flows as it reduces the likelihood 
of dropping multiple packets within a TCP window. The marker also 
works correctly with UDP traffic, i.e., it associates the appropriate 
portion of the UDP packets with yellow or red colour marking if such 
flows transmit at a sustained level above the contracted rate. 


+--------- + 
| Rate | Rate 
lestimator| ========== 
+--------- + 
À V 
| +--------- + 
| | | 
Packet >| Marker |====> Marked packet stream 
Stream | | (Green, Yellow and Red) 
+--------- + 


Figure 1. Block diagram for the TSWTCM 


The colour of the packet is translated into a DS field packet 
marking. The colours red, yellow and green translate into DS 
codepoints representing drop precedence 2, 1 and 0 of a single AF 
class respectively. 


Based on feedback from four different implementations, the TSWICM is 
simple and straightforward to implement. The TSWTCM can be 
implemented in either software or hardware depending on the nature of 
the forwarding engine. 
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3.0 Rate Estimator 


The Rate Estimator provides an estimate of the traffic stream’s 
arrival rate. This rate should approximate the running average 
bandwidth of the traffic stream over a specific period of time 
(AVG_INTERVAL) . 


This memo does not specify a particular algorithm for the Rate 
Estimator. However, different Rate Estimators should yield similar 
results in terms of bandwidth estimation over the same fixed window 
(AVG_INTERVAL) of time. Examples of Rate Estimation schemes include: 
exponential weighted moving average (EWMA) and the time-based rate 
estimation algorithm provided in [TON98]. 


Preferably, the Rate Estimator SHOULD maintain time-based history for 
its bandwidth estimation. However, the Rate Estimator MAY utilize 
weight-based history. In this case, the Estimator used should 
discuss how the weight translates into a time-window such as 
AVG_INTERVAL. 


Since weight-based Estimators track bandwidth based on packet 
arrivals, a high-sending traffic stream will decay its past history 
faster than a low-sending traffic stream. The time-based Estimator is 
intended to address this problem. The latter Rate Estimator utilizes 
a low-pass filter decaying function. [FANG99] shows that this Rate 
Estimator decays past history independently of the traffic stream’s 
packet arrival rate. The algorithm for the Rate Estimator from 
[TON98] is shown in Figure 2 below. 
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Initially: 


AVG_INTERVAL = 
avg-rate = 
t-front 


Upon each packet’s arrival, the rate estimator updates its variables: 


| 

| 

| 

| 

| 

| Bytes_in_win = 

| New_bytes = 

| avg-rate = 

| t-front = 

|Where: 

| now = 
pkt_size = 

| avg-rate = 

| AVG_INTERVAL = 

| 


Figure 


a constant; 
CTR; 
0; 


avg-rate * AVG_INTERVAL; 

Bytes_in_win + pkt_size; 

New_bytes/( now - t-front + AVG_INTERVAL) ; 
now; 


The time of the current packet arrival 

The packet size in bytes of the arriving packet 
Measured Arrival Rate of traffic stream 

Time window over which history is kept 


2. Example Rate Estimator Algorithm 


The Rate Estimator 


MAY operate in the Router Forwarding Path or as a 


background function. In the latter case, the implementation MUST 
ensure that the Estimator provides a reasonably accurate estimation 
of the sending rate over a window of time. The Rate Estimator MAY 
sample only certain packets to determine the rate. 


4.0 Marker 


The Marker determines the colour of a packet based on the algorithm 
presented in Figure 3. The overall effect of the marker on the 
packets of a traffic stream is to ensure that: 


- If the estimated 


average rate is less than or equal to the CTR, 


packets of the stream are designated green. 


- If the estimated 
than or equal to 


average rate is greater than the CTR but less 
the PTR, packets are designated yellow with 


probability PO and designated green with probability (1-P0). 
PO is the fraction of packets contributing to the measured 
rate beyond the CTR. 
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if (avg-rate <= CTR) 
the packet is green; 


(avg-rate 


with probability (1-P0) the 


with probability (1-(P1+P2) ) 


calculate PO = £4---------- 
avg- 
with probability PO the packet is yellow; 


avg-rate = Estimated Avg Sending Rate of Traffic Stream 


else if (avg-rate <= PTR) AND (avg-rate > CTR) 


— CTR) 


rate 


packet is green; 


else 
(avg-rate - PTR) 
calculate Pl =  ---------------- 
avg-rate 
(PTR - CTR) 
calculate P2 = 4----------- 
avg-rate 


with probability Pl the packet is red; 
with probability P2 the packet is yellow; 


the packet is g 


Figure 3. TSWICM Marking Algorithm 


reen; 


- If the estimated average rate is greater than the PTR, 
packets are designated red with probability P1, designated 
yellow with probability P2 and designated green with probability 
(1-(P1+P2)). Pl is the fraction of packets contributing 
to the measured rate beyond the PTR. P2 is the fraction of 
packets contributing to that part of the measured rate 


between CTR and PTR. 


The marker MUST operate in the forwarding path of all packets. 


5.0 Configuration 


5.1 Rate estimator 


If the Rate Estimator is time-based, it should base its bandwidth 


estimate on the last AVG_INTERVAL of time. 


AVG_INTERVAL is 


the 


amount of history (recent time) that should be used by the algorithm 
in estimating the rate. Essentially it represents the window of time 
included in the Rate Estimator’s most recent result. 


The value of AVG_INTERVAL SHOULD be configurable, and MAY be 


specified in either milliseconds or seconds. 
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[TON98] recommends that for the case where a single TCP flow 
constitutes the contracted traffic, AVG_INTERVAL be configured to 
approximately the same value as the RTT of the TCP flow. Subsequent 
experimental studies in [GLOBE99] utilized an AVG_INTERVAL value of 1 
second for scenarios where the contracted traffic consisted of 
multiple TCP flows, some with different RIT values. The latter work 
showed that AVG_INTERVAL values larger than the largest RIT for a TCP 
flow in an aggregate can be used as long as the long-term bandwidth 
assurance for TCP aggregates is measured at a granularity of seconds. 
The AVG_INTERVAL value of 1 second was also used successfully for 
aggregates with UDP flows. 


If the Rate Estimator is weight-based, the factor used in weighting 
history - WEIGHT - SHOULD be a configurable parameter. 


The Rate Estimator measures the average sending rate of the traffic 
stream based on the bytes in the IP header and IP payload. It does 

not include link-specific headers in its estimation of the sending 

rate. 


5.2 Marker 


The TSWICM marker is configured by assigning values to its two 
traffic parameters: Committed Target Rate (CTR) and Peak Target Rate 
(PTR). 


The PTR MUST be equal to or greater than the CTR. 


The CTR and PTR MAY be specifiable in bits per second or bytes per 
second. 


The TSWICM can be configured so that it essentially operates with a 
single rate. If the PTR is set to the same value as the CTR then all 
packets will be coloured either green or red. There will be no yellow 
packets. 


If the PTR is set to link speed and the CTR is set below the PTR then 
all packets will be coloured either green or yellow. There will be no 
red packets. 


6.0 Scaling properties 


The TSWICM can work with both sender-based service level agreements 
and receiver-based service level agreements. 
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7.0 Services 


There are no restrictions on the type of traffic stream for which the 
TSWTCM can be utilized. It can be used to meter and mark individual 
TCP flows, aggregated TCP flows, aggregates with both TCP and UDP 
flows [UDPTCP] etc. 


The TSWICM can be used in conjunction with the AF PHB to create a 
service where a service provider can provide decreasing levels of 
bandwidth assurance for packets originating from customer sites. 


With sufficient over-provisioning, customers are assured of mostly 

achieving their CTR. Sending rates beyond the CTR will have lesser 
assurance of being achieved. Sending rates beyond the PTR have the 

least chance of being achieved due to high drop probability of red 

packets. 


Based on the above, the Service Provider can charge a tiered level of 
service based on the final achieved rate. 


8.0 Security Considerations 
TSWTCM has no known security concerns. 
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12. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Fang, et al. Experimental [Page 9] 


